Когда работаешь над продуктом для массового пользователя, хочется быть уверенным, что UX/UI работает: достаточно ли интерфейс понятен, логичен, удобен, правильно ли работают все его технические элементы. Результатом UX тестирования является перечень рекомендаций, что и каким образом нужно изменить, чтобы повысить количество конверсий и превратить посетителей сайта в его постоянных и преданных пользователей.

Как проводить UX тестирование? На какие моменты обратить внимание? Об этом я расскажу в своём докладе.

В рамках бизнес-игры участники:

1. Составят опросник для сбора требований.
2. Посмотрят на вопросы глазами заказчика.
3. Обработают результаты обследования и сформулируют концепцию предлагаемого решения.

По итогам мы обсудим:

1. Как различные модели поведения представителей заказчика и аналитика влияют на результат обследования.
2. Как выявлять вопросы, на которые аналитик получает «не те» ответы.
3. Как самому проверить полноту и корректность вопросов к заказчику.
4. Типовые ошибки, которые приводят к неправильному пониманию вопросов и получению "не тех" ответов. 
5. Рекомендации по минимизации риска ошибок при сборе требований.

Участники будут работать в командах по 5-6 человек. Каждый участник сможет последовательно поставить себя на место аналитика, заказчика, а затем снова аналитика, примерив при этом разные ролевые модели поведения.

Бизнес-игра состоит из следующих блоков:

1. Вводная часть. Вы узнаете правила игры и разобьетесь на команды.
2. Сбор требований. Каждая команда пройдет полный цикл работ от разработки опросника до формализации концепции предлагаемого решения проблемы заказчика.
3. Подготовка рекомендаций, которые помогут на этапе составления опросника подстраховаться от риска искажения информации. Обсуждение типовых ошибок аналитика при сборе требований.
4. Обратная связь от ведущих игры.

Ведущие бизнес-игры:

Букреева Наталья, ведущий аналитик Croc Code
Астанина Светлана, ведущий аналитик Croc Code
Подклетнев Евгений, старший системный аналитик Croc Code 

Продолжительность бизнес-игры: 2 часа

Существует большое заблуждение, что системное мышление, навыки анализировать и структурировать информацию – это способности, которые даны человеку от рождения.

А еще взрослые люди очень скептически относятся, когда им начинают рассказывать про то, что читать можно как-то по-другому, а не так как их научили в детстве – слог за слогом, слово за словом, страница за страницей

На мастер-классе не будет теории.

1. Сначала мы разомнемся и выполним комплекс упражнений, которые включат ваш мозг в работу. Будет немного шумно и весело.

2. Потом проведем ряд тестов, по результатам которых вы сами сделаете вывод – на что способен ваш мозг.

3. Освоим технологию, позволяющую очень быстро прорабатывать текстовую информацию.

Возьмите с собой книгу (не художественную), которую давно хотели бы изучить, да все никак «руки не доходят» - получите максимум пользы.

Продолжительность 1.5.ч

При составлении бэклога или списка требований часто возникает проблема трассировки задач бизнеса на конкретные фичи продукта. Не всегда из набора фичей складывается ясная картина влияния продукта на целевые метрики бизнеса.

Impact Mapping — это мощная техника выстраивания соответствия целей и конкретных решений. Она позволяет быстро выявить полезную функциональность (и избавиться от бесполезной), приоритезировать состав функций продукта и сфокусироваться на решении задач бизнеса, а не запиливании фич.

Кроме того, техника дает каркас для выработки решений, не связанных с изменением продукта, а лежащих в области изменения процессов и маркетинга.

На мастер-классе участники самостоятельно попробуют применить Impact mapping на учебной задаче, получат фидбэк и разбор всех нюансов построения карт влияния.

Длительность мастер-класса - 2 часа.

Баттл с Сергеем Мартыненко про техники проверки требований.

Тезисы Сергея:

Системный аналитик производит тексты. В истории ИТ постоянно появляются попытки перевести все артефакты в форму диаграмм, но даже в диаграммах есть слова и подписи. Да и не всегда удобны диаграммы оказываются и для разработчиков и для согласующих. В общем, аналитик производит тексты - описания процессов, требования, технические задания. И это тексты на естественном языке. А естественный язык - это не формальная система. В словах куча неоднозначностей, умолчаний, двусмысленностей, недоговоренности, подразумеваемых значений... И если такие слова просачиваются в тексты требований - жди беды. В докладе я расскажу про требования к текстам требований (и даже приведу выдержки из соответствующих стандартов) и дам список "стоп-слов" - таких слов и выражений, при встрече которых в документе или на диаграмме у аналитика должна мысленно "загораться красная лампочка" и включаться сигнал тревоги. Очистим тексты аналитиков от двусмысленностей и неоднозначностей! Доведем тексты требований до совершенства!

В кровавом энтерпрайзе есть задача — настроить загрузку данных из одной информационной системы в другую. Например, вы работаете в банке, и к хранилищу данных постоянно подключаются новые источники — личный кабинет, CRM, MDM, АБС и т.д.

Эта задача может легко превратиться в кромешный ад для всех участников. Например, бизнес ждет данные в онлайне, а у источника нет API для его передачи и идут регулярные пакетные загрузки. Результат – интеграция тормозит или вообще не реализуется, задача бизнеса не решена.

Расскажу, что нужно узнать про систему-источник до старта разработки, чтобы минимизировать проблемы как для системы-потребителя, так и для других систем в ландшафте. Обсудим, когда смысла в интеграции и вовсе нет – ведь если можно что-то не делать, то зачем вкладывать в это время и силы?

В IT есть два типа людей: те, кто пропагандирует использование REST API, и те, кто его не ненавидит. Мы встанем на третью сторону и посмотрим, какие границы применимости имеет эта концепция при проектировании API.

На воркшопе спроектируем HTTP API в рамках REST парадигмы и обсудим сложности, которые возникнут в процессе. После рассмотрим менее очевидные проблемы при использовании REST API.

Будет полезен для специалистов, имеющих опыт проектирования реальных или учебных REST API.

Длительность: 90 минут

При миграции с монолита большой информационной системы не всегда есть возможность реализовать классический DDD. Зачастую распил монолита осуществляется по частям, границы этого перевода задаются очень жесткими рамками, а бизнес боится потерять бизнес процессы и бизнес в целом. В этих условиях “голубого океана” для полноценной реализации DDD нет.

В своем докладе я хочу рассказать о технике параллельного моделирования бизнес-процессов и концептуальной модели предметной области, которая позволяет обеспечить  целостность бизнес-процессов и при этом обеспечивает изоляцию проектирумых микросервисов.

Доклад основывается на практическом опыте работы в роли системного аналитика на примере пилотного проекта по “распилу” монолита на микросервисы .